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Copyright Notice 
Copyright (C) The IETF Trust (2007). 

Abstract 
This document specifies media type registrations for the RTP payload 
formats defined in the RTP Profile for Audio and Video Conferences. 


Some of these may also be used for transfer modes other than RTP. 
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Les 


1. 


Introduction 


This document updates the media type registrations initially 
specified in RFC 3555 for the Real-time Transport Protocol (RTP) 
payload formats defined in the RIP Profile for Audio and Video 
Conferences, RFC 3551 [1], as subtypes under the "audio" and "video" 
media types. This document does not include media type registrations 
for the RTP payload formats that are referenced in RFC 3551 but 
defined in other RFCs. The media type registrations for those 
payload formats are intended to be updated by including them in 
revisions of the individual RFCs defining the payload formats. 


The media type registrations specified here conform to the updated 
template format and procedures in RFC 4288 [2] and RFC 4855 [3]. 
This update makes no technical changes in the registrations. 
Together with RFC 4855, this document obsoletes RFC 3555. 


1. IANA Considerations 


As a consequence of the generalized applicability of the media types 
registry as specified in RFC 4288, some changes in nomenclature are 
needed in the RTP Payload Format section of the registry. In the 
registry title "RTP Payload Format MIME types" and the introductory 
text, "MIME" should be changed to "media". "MIME" should be deleted 
from the table headings, leaving just "media type" and "subtype". 


This document updates the media type registrations listed below to 
conform to the revised registration format specified in RFC 4288 and 
RFC 4855, so the reference for these media types should be changed 
from RFC 3555 to this document. Some media type registrations 
contained in RFC 3555 are omitted from this document; the existing 
registrations for those types continue to be valid until updated by 
other RFCs. There are no new registrations contained here. 
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audio/DVI4 
audio/G722 
audio/G723 
audio/G726-16 
audio/G726-24 
audio/G726-32 
audio/G726-40 
audio/G728 
audio/G729 
audio/G729 
audio/G729 
audio/GSM 
audio/GSM-EFR 
audio/L8 
audio/L16 
audio/LPC 
audio/PCMA 
audio/PCMU 
audio/VDVI 
video/nv 


Gl O 


Media type audio/L16 was initially registered via RFC 2586 for 
transports other than RTP. That registration is incorporated here 
and augmented with additional information for RIP transport. 


1.2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [4] and 
indicate requirement levels for implementations compliant with this 
specification. 


2. Registrations for "Audio/Video Profile" 
In the following sections, the RTP payload formats defined in the RTP 
Profile for Audio and Video Conferences, RFC 3551 [1], are registered 
as media types. 

2.1. Audio Type Registrations 
For most audio payload formats, the RTP timestamp clock rate is equal 
to the sampling rate. Some payload formats operate only at one fixed 


sampling rate, while others are adjustable. 


These audio formats also include the optional parameters "ptime" to 
specify the recommended length of time in milliseconds represented by 
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the media in a packet, and "maxptime" to specify the maximum amount 
of media that can be encapsulated in each packet, expressed as time 
in milliseconds. The "ptime" and "maxptime" parameters are defined 
in the Session Description Protocol (SDP), RFC 4566 [5]. 


2.1.1. Registration of Media Type audio/DVI4 

Type name: audio 

Subtype name: DVI4 

Required parameters: 
rate: The RTP timestamp clock rate, which is equal to the 
sampling rate. The typical rate is 8000, but other rates may 
be specified. 

Optional parameters: ptime, maxptime (see RFC 4566) 

Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 

Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 

Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 

Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550 [6]). Transfer within 


other framing protocols is not defined at this time. 


Author: 
Stephen Casner 
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Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 

2.1.2. Registration of Media Type audio/G722 

Type name: audio 

Subtype name: G722 

Required parameters: none 

Optional parameters: ptime, maxptime (see RFC 4566) 

Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 

Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 

Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 


IETF Audio/Video Transport working group delegated from the 
IESG. 
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2.1.3. Registration of Media Type audio/G723 
Type name: audio 
Subtype name: G723 
Required parameters: none 


Optional parameters: 
ptime, maxptime: see RFC 4566 


bitrate: the data rate in kb/s used or preferred for the audio 
bit stream, with permissible values 5.3 or 6.3. If 
unspecified, the bitrate may change from frame to frame as 
indicated inband. 


annexa: indicates that Annex A, voice activity detection, is 
used or preferred. Permissible values are "yes" and "no" 
(without the quotes); "yes" is implied if this parameter is 
omitted. 


Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288). 
Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 
Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 
Restrictions on usage: 
This media type depends on RTP framing, and hence is only 


defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 
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Author: 
Stephen Casner 
Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 
2.1.4. Registration of Media Type audio/G726-16 
Type name: audio 
Subtype name: G726-16 
Required parameters: none 
Optional parameters: ptime, maxptime (see RFC 4566) 
Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 
Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 
Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 

Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 


other framing protocols is not defined at this time. 


Author: 
Stephen Casner 
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Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 

2.1.5. Registration of Media Type audio/G726-24 

Type name: audio 

Subtype name: G726-24 

Required parameters: none 

Optional parameters: ptime, maxptime (see RFC 4566) 

Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 

Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 

Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 


IETF Audio/Video Transport working group delegated from the 
IESG. 


Casner Standards Track [Page 8] 


RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 


2.1.6. Registration of Media Type audio/G726-32 

Type name: audio 

Subtype name: G726-32 

Required parameters: none 

Optional parameters: ptime, maxptime (see RFC 4566) 

Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288). 

Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 

Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 


IETF Audio/Video Transport working group delegated from the 
IESG. 


Casner Standards Track [Page 9] 


RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 


2.1.7. Registration of Media Type audio/G726-40 

Type name: audio 

Subtype name: G726-40 

Required parameters: none 

Optional parameters: ptime, maxptime (see RFC 4566) 

Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288). 

Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 

Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 


IETF Audio/Video Transport working group delegated from the 
IESG. 
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2.1.8. Registration of Media Type audio/G728 

Type name: audio 

Subtype name: G728 

Required parameters: none 

Optional parameters: ptime, maxptime (see RFC 4566) 

Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288). 

Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 

Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 


IETF Audio/Video Transport working group delegated from the 
IESG. 
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.1.9. Registration of Media Type audio/G729 
Type name: audio 

Subtype name: G729 

Required parameters: none 


Optional parameters: 
ptime, maxptime: see RFC 4566 


annexb: indicates that Annex B, voice activity detection, is 
used or preferred. Permissible values are "yes" and "no" 
(without the quotes); "yes" is implied if this parameter is 
omitted. 


Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 
Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 
Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 


Author: 
Stephen Casner 
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Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 
2.1.10. Registration of Media Type audio/G729D 
Type name: audio 
Subtype name: G729D 


Required parameters: none 


Optional parameters: 
ptime, maxptime: see RFC 4566 


annexb: indicates that Annex B, voice activity detection, is 
used or preferred. Permissible values are "yes" and "no" 
(without the quotes); "yes" is implied if this parameter is 
omitted. 


Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 
Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 
Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 
Restrictions on usage: 
This media type depends on RTP framing, and hence is only 


defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 
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Author: 
Stephen Casner 
Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 
2.1.11. Registration of Media Type audio/G729E 
Type name: audio 
Subtype name: G729E 


Required parameters: none 


Optional parameters: 
ptime, maxptime: see RFC 4566 


annexb: indicates that Annex B, voice activity detection, is 
used or preferred. Permissible values are "yes" and "no" 
(without the quotes); "yes" is implied if this parameter is 
omitted. 
Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 
Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 
Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 
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Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 

2.1.12. Registration of Media Type audio/GSM 

Type name: audio 

Subtype name: GSM 

Required parameters: none 

Optional parameters: ptime, maxptime (see RFC 4566) 

Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 

Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 

Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 
Restrictions on usage: 
This media type depends on RTP framing, and hence is only 


defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 
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Author: 
Stephen Casner 
Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 
2.1.13. Registration of Media Type audio/GSM-EFR 
Type name: audio 
Subtype name: GSM-EFR 
Required parameters: none 
Optional parameters: ptime, maxptime (see RFC 4566) 
Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 
Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 
Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 

Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 


other framing protocols is not defined at this time. 


Author: 
Stephen Casner 
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Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 
2.1.14. Registration of Media Type audio/L8 
Type name: audio 


Subtype name: L8 


Required parameters: 
rate: the RTP timestamp clock rate 


Optional parameters: 
channels: how many audio streams are interleaved -- defaults 
to 1; stereo would be 2, etc. Interleaving takes place 
between individual one-byte samples. The channel order is as 
specified in RFC 3551. 


ptime, maxptime: see RFC 4566 
Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288). 
Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 
Interoperability considerations: none 


Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 
Restrictions on usage: 
This media type depends on RTP framing, and hence is only 


defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 
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Author: 
Stephen Casner 


Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 


2.1.15. Registration of Media Type audio/L16 


Media type audio/L16 was initially registered via RFC 2586 [10] for 
transports other than RTP. That registration is incorporated here 
and augmented with additional information for RTP transport. 


Type name: audio 
Subtype name: L16 


Required parameters: 
rate: number of samples per second -- For non-RTP transport, 
the permissible values for rate are 8000, 11025, 16000, 22050, 
24000, 32000, 44100, and 48000 samples per second. For RTP 
transport, other values are permissible but the aforementioned 
values are RECOMMENDED. For RTP, the rate parameter indicates 
the RTP timestamp clock rate, which is equal to the sample 
rate. 


Optional parameters: 
channels: how many audio streams are interleaved -- defaults 
to 1; stereo would be 2, etc. Interleaving takes place 
between individual two-byte samples. The channel order is as 
specified in RFC 3551 unless a channel-order parameter is also 
present. 


emphasis: analog preemphasis applied to the signal before 
quantization. The only emphasis value defined here is 
emphasis=50-15 to indicate the 50/15 microsecond preemphasis 
used with Compact Discs. This parameter MUST be omitted if no 
analog preemphasis was applied. Note that this is a stream 
property parameter, not a receiver configuration parameter. 
Thus, if parameters are negotiated, it may not be possible for 
the sender to comply with a receiver request for a particular 
setting. 


channel-order: specifies the sample interleaving order for 
multiple-channel audio streams (see RFC 3190 [7], Section 7). 
Permissible values are DV.LRLSRs, DV.LRCS, DV.LRCWo, 
DV.LRLSRsC, DV.LRLSRSCS, DV.LmixRmixTWoQ1Q2, 
DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1RslLs2Rs2, DV.LRCWoLsRsLcRc. 
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For interoperation with DV video systems, only a subset of 
these channel combinations is specified for use with 20-bit 
linear encoding in the DV video specification [9]; those are 
DV.LRLsSRs, DV.LRCS, DV.LmixRmixTWoQ102. This parameter MUST 
be omitted when the AIFF-C channel order convention (see RFC 
3551) is in use. 


For RTP, ptime: RECOMMENDED duration of each packet in 
milliseconds. 


For RTP, maxptime: maximum duration of each packet in 
milliseconds. 


Encoding considerations: 
Audio data is binary data, and must be encoded for non-binary 
transport; the Base64 encoding is suitable for Email. Note 
that audio data does not compress easily using lossless 
compression. 


Security considerations: 
Audio/L16 data is believed to offer no security risks. This 
media type does not carry active content. The encoding is not 
compressed. See Section 4 of RFC 4856. 


Interoperability considerations: 
This type is compatible with the encoding used in the WAV 
(Microsoft Windows RIFF) and Apple AIFF union types, and with 
the public domain "sox" and "rateconv" programs. 


Published specification: 
RFC 2586 for non-RTIP transports, RFC 3551 for RTP 


Applications that use this media type: 
The public domain "sox" and "rateconv" programs accept this 
type. 


Additional information: 
Magic number(s): none 
File extension(s): WAV L16 
Macintosh file type code: AIFF 


Person to contact for further information: 
James Salsman <jps-L16@bovik.org> 
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Intended usage: 
Common 


It is expected that many audio and speech applications will 
use this type. Already the most popular platforms provide 
this type with the rate=11025 parameter, referred to as "radio 
quality speech". 


Restrictions on usage: 
In addition to file-based transfer methods, this type is also 
defined for transfer via RTP (RFC 3550). 

Author: 
James Salsman for non-RTP transports. 
Stephen Casner for RTP transport. 

Change controller: 
James Salsman for non-RTP transports. 
For RTP transport, IETF Audio/Video Transport working group 
delegated from the IESG. 

2.1.16. Registration of Media Type audio/LPC 

Type name: audio 

Subtype name: LPC 

Required parameters: none 


Optional parameters: ptime, maxptime (see RFC 4566) 


Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 


4288) . 

Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 


Interoperability considerations: none 
Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 
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Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 


2.1.17. Registration of Media Type audio/PCMA 
Type name: audio 
Subtype name: PCMA 
Required parameters: 
rate: The RTP timestamp clock rate, which is equal to the 


sampling rate. The typical rate is 8000, but other rates may 
be specified. 


Optional parameters: 
channels: how many audio streams are interleaved -- defaults 
to 1; stereo would be 2, etc. Interleaving takes place 
between individual one-byte samples. The channel order is as 
specified in RFC 3551. 


ptime, maxptime: see RFC 4566 

Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 

Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 


Interoperability considerations: none 


Published specification: RFC 3551 
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Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 


2.1.18. Registration of Media Type audio/PCMU 
Type name: audio 
Subtype name: PCMU 


Required parameters: 
rate: The RTP timestamp clock rate, which is equal to the 
sampling rate. The typical rate is 8000, but other rates may 
be specified. 


Optional parameters: 
channels: how many audio streams are interleaved -- defaults 
to 1; stereo would be 2, etc. Interleaving takes place 
between individual one-byte samples. The channel order is as 
specified in RFC 3551. 


ptime, maxptime: see RFC 4566 

Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 

Security considerations: 


This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 
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Interoperability considerations: none 
Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 

Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 


other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 

2.1.19. Registration of Media Type audio/VDVI 

Type name: audio 

Subtype name: VDVI 

Required parameters: none 

Optional parameters: ptime, maxptime (see RFC 4566) 

Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 

Security considerations: 
This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 


Interoperability considerations: none 


Published specification: RFC 3551 
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Applications that use this media type: 
Audio and video streaming and conferencing tools. 
Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 

Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 


other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 
2.2. Video Type Registrations 
For most video payload formats, including the one registered here, 
the RTP timestamp clock rate is always 90000 Hz, so the "rate" 
parameter is not applicable. Likewise, the "channel" parameter is 
not used with video, while "ptime" and "maxptime" could be but 
typically are not. 
2.2.1. Registration of Media Type video/nv 
Type name: video 
Subtype name: nv 
Required parameters: none 
Optional parameters: none 
Encoding considerations: 
This media type is framed binary data (see Section 4.8 in RFC 
4288) . 
Security considerations: 


This media type does not carry active content. It does 
transfer compressed data. See Section 4 of RFC 4856. 
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Interoperability considerations: none 
Published specification: RFC 3551 


Applications that use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Restrictions on usage: 
This media type depends on RTP framing, and hence is only 
defined for transfer via RTP (RFC 3550). Transfer within 
other framing protocols is not defined at this time. 


Author: 
Stephen Casner 


Change controller: 
IETF Audio/Video Transport working group delegated from the 
IESG. 


3. Changes from RFC 3555 


RFC 3555 is obsoleted by the combination of RFC 4855 [3] and this 
document. RFC 4855 retains the specification of procedures and 
requirements from RFC 3555, while the media type registrations from 
RFC 3555 were extracted into this document. The media type 
registrations for the RTP payload formats that are referenced in RFC 
3551 [1], but defined in other RFCs, have been elided from this 
document because those registrations are intended to be updated by 
including them in revisions of the individual RFCs defining the 
payload formats. 


The media type registrations in this document have been updated to 
conform to the revised media type registration procedures in RFC 4288 
[2] and RFC 4855. Whereas RFC 3555 required the encoding 
considerations to specify transfer via RTP, that is now specified 
under restrictions on usage. The encoding considerations now warn 
that these types are framed binary data. The change controller is 
also now identified according to current conventions. The optional 
parameter "channels" was clarified for audio subtypes L8, PCMA, and 
PCMU. Finally, reference [9], which was missing from RFC 3555, has 
been corrected. 
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4. 


Security Considerations 


This memo specifies media type registrations for the transfer of 
several compressed audio and video data encodings via RTP, so 
implementations using these media types are subject to the security 
considerations discussed in the RTP specification [8]. 


None of these media types carry "active content" that could impose 
malicious side-effects upon the receiver. The content consists 
solely of compressed audio or video data to be decoded and presented 
as sound or images. However, several audio and video encodings are 
perfect for hiding data using steganography. 


A potential denial-of-service threat exists for data encodings using 
compression techniques that have non-uniform receiver-end 
computational load. The attacker can inject pathological datagrams 
into the stream, which are complex to decode and cause the receiver 
to be overloaded. However, none of the encodings registered here has 
an expansion factor greater than about 20, and all are considered 
relatively simple by modern standards (some are implemented on 
handheld devices and most were implemented on general-purpose 
computers ten years ago). 


As with any IP-based protocol, in some circumstances a receiver may 
be overloaded simply by the receipt of too many packets, either 
desired or undesired. Network-layer authentication MAY be used to 
discard packets from undesired sources, but the processing cost of 
the authentication itself may be too high. 


RTP may be sent via IP multicast, which provides no direct means for 
a sender to know all the receivers of the data sent and therefore no 
measure of privacy. Rightly or not, users may be more sensitive to 
privacy concerns with audio and video communication than they have 
been with more traditional forms of network communication. 

Therefore, the use of security mechanisms with RIP to provide 
confidentiality and integrity of the data is important. Because the 
data compression used with these media types is applied end-to-end, 
encryption may be performed after compression so there is no conflict 
between the two operations. 
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